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Abstract —Software debugging is a very time-consuming pro¬ 
cess, which is even worse for multi-threaded programs, due to 
the non-determlnistlc behavior of thread-scheduling algorithms. 
However, the debugging time may be greatly rednced, if antomatic 
methods are nsed for localizing fanits. In this study, a new method 
for fault localization, in multi-threaded C programs, is proposed. 
It transforms a multi-threaded program into a corresponding 
seqnential one and then uses a fault-diagnosis method suitable 
for this type of program, in order to localize faults. The code 
transformation is implemented with rules and context switch 
information from connterexamples, which are typically generated 
by bounded model checkers. Experimental resnits show that the 
proposed method is effective, in such a way that sequential fault- 
localization methods can be extended to multi-threaded programs. 

Keywords — Multi-threaded Software, Bounded Model Checking, 
Fault Localization. 

I. Introduction 

Recently, it has become more and more common for 
technology to handle various tasks in everyday life, each one 
with an associated complexity. Ensuring that systems work 
properly imply in cost reduction and even, in some areas, 
that lives are safe. This is what makes program debugging 
so worthy of attention in computer-based systems. Program 
debugging is a very important but time-consuming task, in 
software development processes, which can be divided into 
three steps: fault detection, fault localization, and fault correc¬ 
tion. However, the associated debugging time can be largely 
reduced, if automatic methods are used for localizing faults, 
especially in multi-threaded programs, which are widely used 
in embedded system products. 

A number of different approaches have been introduced, 
in order to provide automated methods for localizing faults in 
applications, based on the generation of a program model that 
is extracted from its source code HI. Those include slicing ||2|, 
mutation testing 0, trace-based analysis a, delta-debugging 
0, model-based debugging 0, and model checking ||71. In 
this paper, a fault localization method is proposed, which relies 
entirely on model-checking techniques. In particular. Bounded 
Model Checking (BMC) based on Satisfiability Modulo Theo¬ 
ries (SMT) is used to automatically refute a safety property 
and consequently produce a counterexample, if the (multi¬ 
threaded) program does not satisfy a given specification. It 
is worth noticing that the generated counterexamples may 
be regarded as error traces, which contain useful information 
about faults, so that one can localize and correct them. 

The C Bounded Model Checker (CBMC) |[8| and also the 
Efficient SMT-Based Context-Bounded Model Checker (ES- 


BMC) 0 are both well known BMC tools, which are suitable 
for verifying multi-threaded C programs. Since the majority 
of the initiatives, in multi-threaded software verification, have 
focused on Java, as shown by Park, Harrold, and Vuduc IfTOl . 
this study suggests an automated fault localization method 
for multi-threaded C programs, using SMT-based BMC tech¬ 
niques. In particular, in this present work, ESBMC 0 is 
adopted, since it is one of the most efficient verifiers, as 
reported by Beyer CD, and it also supports both single- and 
multi-threaded programs, using different SMT solvers to check 
for the generated verification conditions (VCs) ifT^ . 

Two main goals are achieved here: the evaluation of the 
method proposed by Griesmeyer, Staber, and Bloem ca and 
the improvement/extension of this same method, in order 
to support multi-threaded applications. The basic concept of 
extending the mentioned work ifTSi consists in transforming a 
multi-threaded program into a corresponding sequential one, 
by carrying out evaluation and transformation steps, and then 
using that work for localizing faults. As a consequence, the 
found violations, in the sequential code, can show the location 
of the initial faults, in the original multi-threaded program. 

This paper is organized as follows. Section El describes 
the related work. Eault localization based on model checking is 
introduced in section [HI] The method proposed by Griesmeyer, 
Staber, and Bloem ca is also tackled, in detail, in section 
uni Section |IV] is the main section of the present paper and 
demonstrates the proposed method for fault localization, in 
multi-threaded programs. Section |V] provides experimental re¬ 
sults, analysis, and discussion. Einally, section m summarizes 
the main results and highlights future work. 


II. Related work 

Cleve et al. 0 show how cause transitions, which are mo¬ 
ments where a variable replaces another as failure cause, can 
locate defects in programs. Such an achievement is possible 
due to a comparison regarding program states of failing and 
passing runs; however, given that such state differences can 
occur all over the program run, the focus is in space, with a 
subset of variables that is relevant to the failure occurrence, 
and also in time, where cause transitions occur. 

Griesmeyer et al. ns proposed a method for localizing 
faults, in ANSTC programs, by instrumenting the original code 
and running that new version on a model checker. Such an 
approach is very helpful, given that model checkers are able to 
identify the exact fault line; however, this work only presented 
a method for sequential programs IISl. 


Birch et al. ca describe a method for fast model-based 
fault localization, which, given a test suite, automatically 
identifies a small subset of program locations, where faults 
exist, by using symbolic execution methods. In summary, the 
mentioned algorithm tries to find counterexamples that are 
capable of localizing faults, based on failing test cases from 
a test suite. The key factor to its speed is that if an execution 
takes longer than expected, it is pushed into a queue, for later 
handling, and then another execution is chosen to be run. 

Jones et al. El showed how test information visualization 
can assist in fault localization. By coloring program statements 
that participate in the outcome of a program execution, with a 
test suite, it is possible to assist users to inspect code, evaluate 
statements involved in failures, and identify possible faults. 

Jose et al. El reported a method to localize faults in 
programs, using a reduction to the Maximal Satisfiability 
Problem, which informs the maximum number of clauses, of 
a Boolean formula, that can simultaneously be satisfied by an 
assignment. The potential error is given by finding the maximal 
set of clauses that can be satisfied, in a formula generated by 
combining a failing program execution and a Boolean trace 
formula, and outputting the complement set. 

Tomasco et al. El presented an approach for symbolically 
verifying multi-threaded programs, with shared memory and 
dynamic thread creation, by using a technique called Memory 
Unwinding (MU), which is the process of writing operations 
into shared memory. A code-to-code transformation from 
multi-threaded to sequential programs was used, following MU 
rules, and then checked by a sequential verification tool. 

The closest related work is that of Park et al. El, which 
describe a dynamic fault localization method to localize the 
root causes of concurrency bugs in Java programs, based on 
dynamic pattern detection and statistical fault localization. To 
the best of our knowledge, this present paper marks the first 
application of a fault-localization method, based on BMC 
techniques, to a broader range of multi-threaded C programs. 

III. Background 

A. Bounded Model Checking to Multi-threaded Software 

The basic idea of BMC applied to multi-threaded software 
is to check for the negation of a given property, at a given 
depth El- Given a reachability tree T = {i^i,..., which 
represents the program unfolding for a context bound C and a 
bound k, and a property BMC derives a VC for a given 
interleaving (or computation path) n = {vi,... ,Vk}, such that 

is satisfiable if and only if f has a counterexample of 
depth k, which is exhibited by tt. The VC V'fc is a quantifier- 
free formula in a decidable subset of first-order logic, which 
is checked for satisfiability by an SMT solver m. The model 
checking problem associated with SMT-based BMC, of a given 
TT, is formulated by constructing the logical formula IfT^ 

constraints property 

tpl = I{so) A R{so,si) A ... A R{sk-i,Sk) A ■ ( 1 ) 

Here, fk represents a safety property in step k, I is the 
set of initial states, and R{si, Si+i) is the transition relation at 
time steps i and i -f 1, as described by the states in tt nodes. 
In order to check if ([T]l is satisfiable or unsatisfiable, the SMT 


solver constrains some symbols, by a given background theory 
{e.g., arithmetic restricts the interpretation of symbols such as 
+, <, 0, and 1) El- If O is satisfiable, then f is violated 
and the SMT solver provides a satisfying assignment, from 
which one can extract values of program variables to construct 
a counterexample, i.e., a sequence of states sq, si,..., Sk, with 
So C So, and transition relations R{si, Si+i), for 0 < i < k. 
If o is unsatisfiable, one can conclude that no error state is 
reachable, in length k along tt. 

B. Fault Localization using Model Checking 

The most basic task regarding fault localization, in model 
checking, is to generate a counterexample, which is provided 
when a program does not satisfy a given specification. Ac¬ 
cording to Clarke et al. lEoi, im, a counterexample does not 
solely provide information about the cause-effect relation of 
a given violation, but also about fault localization. However, 
since an enormous amount of information is presented in a 
counterexample, actual fault lines may not be easily identified. 

Several methods have been proposed, in order to localize 
possible fault causes, through counterexamples. An approach 
proposed by Ball, Naik, and Rajamani ll22l tries isolating 
possible causes of counterexamples, which are generated by 
the SLAM model checker ll23l . In summary, potential fault 
lines can be isolated by comparing transitions among obtained 
counterexamples and successful traces, since transitions not 
included in correct traces are possible causes of errors. Groce 
and Visser Il24l state that if a counterexample exists, a similar 
but successful trace can also be found, using BMC techniques. 
Program elements related to a given violation are implicated 
by the minimal differences between that counterexample and 
a successful trace, which is known as the Java Pathfinder 
approach ll25l and can also provide execution paths that lead 
to error states, regarding for multi-threaded programs {e.g., 
data race). The essence of the approach described by Groce et 
al. 12^ is similar to the latter and uses alignment constraints to 
associate states, in a counterexample, with corresponding states 
in a successful trace, which was generated by a constraint 
solver. The mentioned states are abstract states over predicates, 
which represent concrete states in a trace. By using distance 
metric properties, constraints can be employed for representing 
program executions, and non-matching constraints that rep¬ 
resent concrete states might lead to faults. Additionally, if a 
distance metric property is not satisfied, a counterexample is 
generated by the BMC tool ||26l. 

In contrast to the transition-based and difference-based 
methods mentioned above, a method can directly identify 
possible faults by combining instrumented programs and BMC, 
as shown by Griesmeyer et al. El, El, El, which will be 
further demonstrated. The approach proposed in the present 
paper is based on that method and consists in an extension to 
multi-threaded programs, that is, it tries to identify fault lines 
in multi-threaded programs, using BMC techniques. 

C. Method demonstration 

The method proposed by Griesmeyer et al. El is based 
on the BMC technique, which can directly identify possible 
faults in programs. In particular, this method adds additional 
numerical variables (e.g., diagl, . . ., diagn)) to identify 



a fault in a given program. Each line of a program, representing 
a statement S, is changed to a logic version of that statement. 
As a consequence, the value held by S will be either non- 
deterministically chosen by the BMC tool, if the value of diag 
is the same as the one representing the line related to statement 
S, or the one originally specified. 

If the BMC tool identifies a diag value, by correcting this 
line in the original program, the fault can be avoided. In the 
case of multiple diag values, correcting those lines lead to a 
successful code execution. In order to find the full set of lines 
that cause a faulty behavior in a program, a new lin^i] can be 
added to its source code, which is then rerun in the BMC tool. 
This process is repeatedly executed, until no more values of 
diag are obtained {i.e., the run succeeds) ca. 

As an example, a simple program slightly modified from 
Griesmeyer et al. Ea, is presented in Fig. [T] Its modified 
version, using the mentioned method lIZTl and ready to be run 
by a BMC tool, is shown in Fig. |2] The diagnosis informed by 
a BMC tool is diag == 4 and diag == 7, which means 
that changing line 4 (to “a = 6”) or line 7 (to if (0)), in 
the original program, can result in source code that is able to 
successfully execute, therefore, one can note that the example 
below contains a single fault. 


int nondet(); 
void main() { 
int a, b, c, d; 
int diag; 
diag = nondet (); 
a = 5; b = 2; c = 7; 
if (diag == 4? nondet(): a) 
a = (diag == 6? nondet(): 
b = (diag == 7? nondet(): 
c = (diag == 8? nondet(): 
if (diag == 9? nondet(): 
int d; 

a = (diag == 12? nondet(): 

} 

assume (c == 8); 

} 

assert (false ); 


{ 

5); 

2 ); 

(a + b)); 
(a%2==0)) { 


d); 


Fig. 2. The diagnosis model of the example shown in Fig. [T] where nondet() 
represents a non-deterministic function. 


sequential version and, finally, order control is included into 
the latter, specifying the order in which threads are executed. 
These steps are summarized in Fig. |3] 
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void main() { 
int a, b, c, d; 
if (a) { 
a = 5; 
b = 2; 
c = a + b; 
if (a % 2 == 0) { 
int d; 
a = d; 

} 

assert (c == 8); 

} 


Fig. 1. A simple ANSI-C program with a single fault. 


IV. Fault Focalization in Multi-Threaded C 
Programs using BMC 

The proposed method, which has the goal of localizing 
faults in multi-threaded C programs, is based on Griesmeyer’s 
method im and counterexamples generated by BMC tools, 
such as ESBMC. Its key concept is to transform a multi¬ 
threaded program into a corresponding sequential one and then 
apply instrumentation for identifying faults lIZTll . 



A. Transformations from Multi- to Single-threaded Programs 

The transformation from multi-threaded programs into se¬ 
quential ones can be split into four distinct steps. First, coun¬ 
terexamples are obtained from a BMC tool, which contain use¬ 
ful pieces of information related to faults. Then, the framework 
described below is applied, which consists in code used as 
fixed structure for a new sequential version, together with the 
use of some rules (defined later in section IIV-B2I) . Following 
that, an original (multi-threaded) program is converted into its 

'assume (diag ! = a) (a is the line number obtained in the last run) 


Fig. 3. Proposed method for fault localization in multi-threaded software. 

A framework provides the same execution sequence as 
in the original program. It consists basically in writing each 
thread code inside a case statement, and their execution 
sequence is specified in the order array. Such a framework 
is used as the basic structure for new sequential versions of 
multi-threaded programs, and Fig. |4] shows how it is encoded. 

As one can note, the mentioned framework provides new 
fixed positions, for each part of the original code, and Table U 
shows the relation between new positions and code-fragment 















1 

int order[ 1 ] = { 1 }; 

2 

int main(int argc , char >i<argv []) { 

3 

int order_index ; 

4 

for (order_index= 0; order_index < 1; 

5 

order_index++) { 

6 

switch(order[order_index]) { 

7 

case 1: 

8 

case 11: { ... } 

10 

case 20: { ... } 

11 

break ; 

12 

case 2: 

13 

case 21: { ... } 

14 


15 

case 30: { ... } 

16 

break ; 

17 

case 3: 

18 

case 31: { ... } 

19 


20 

case 40: { ... } 

21 

break ; 

22 


23 

default : 

24 

break ; 

25 

} 

26 

} 

27 

return 1; 

28 

} 


Fig. 4. The standai'd framework to localize faults in sequential code. 

types, that is, it summarizes how the new sequential code 
is structured. In particular, global elements, global variables, 
header hie declarations, and other types of global declarations 
are placed before the sequential code main function. The body 
of its main function, in the original code, is placed between 
the case 1 statement and its respective break command, the 
body of the hrst thread is placed between case 2 and its 
respective break command, and so on. This process is repeated 
until there are no more threads to be inserted into the sequential 
code version. Additionally, arguments passed to the original 
program main function are all passed to the sequential version 
main one. In cases where threads are partially executed, 
a context switch occurs, another thread is executed, or a 
previous thread continues to execute from where it stopped, 
the respective pieces of code are inserted into each case inside 
the case (the case represents the thread), in such 
a way that the execution order remains the same. 


TABLE I. Relation between positions and codes 


Code Fragment Type 

Position in the 

in the Original Code 

New Sequential Code 

global elements 

before line 1 

main function body 

between “case 1” and “break” 

thread body n 

between “case n + 1” and “break” 


In order to maintain the same execution order found in the 
original program, switch order control is required. A fixed con¬ 
text switch order, from a counterexample of a multi-threaded 
program, can be copied to a new sequential one by controlling 
“case” and conditional statement^, in the framework switch 
statement. In general, adding context switch order control to 
the new sequential program can be divided into two steps. 


In order to show a simple situation for illustrating that, it 
is assumed that there are less than 10 context switches in 
each thread (yNti,Nti < 10), a counterexample, given by a 
BMC tool, has N context switches, and from those N context 
switches, Nto occur in the main function, Nti occur in thread 
1, Nt 2 in thread 2, and so on {Nto + + Ntn = N). 

The hrst step is to get information from counterexamples 
generated by a BMC tool, i.e., the total number of context 
switches in the original program and in each thread, the order 
of all context switches in the entire program and also in a single 
thread, and the corTesponding position where a context switch 
occurred. With such data, it is possible to add conditional 
statements^ for maintaining the same execution order of the 
original program, so that when a line is executed, the sequential 
code executes the next case statement, which represents the 
next thread in the original code. 

One can note that if there are iteration statements in the 
original multi-threaded program, for every iteration statement, 
a global variable named “loopcounter” is added. Besides, a 
statement to increment the value of loopcounter is also added 
to the end of each loop body. This newly added global variable 
is used as a condition to directly control the validity of break 
statements, so that when a context switch occurs, inside a loop, 
then the value held by loopcounter must also be used in the 
respective break statement, in order to maintain the original 
program execution sequence. 

The second step consists in modifying values related to the 
order array, in such a way that the execution order in kept, 
in a new sequential program. By changing lines 1 and 4, in 
Fig. a according to the specihc number of occurred context 
switches and their execution order, it is possible to guarantee 
the original execution order, since a switch statement (line 
6) selects which piece of code (representing threads from the 
original program) is executed, based on order [order_index]. 
For instance, if the execution order of the original code is 
thread 0, thread 2, and thread 1 (note that this information 
was previously extracted from the counterexample), the order 
array will hold 11, 31, and 21, meaning that the hrst case will 
be executed, then the third and, hnally, the second one. 

B. Code Transformation 

1) Grammar: Transformation rules, regarding code frag¬ 
ments, are needed, when code fragments are added to corre¬ 
sponding positions in the mentioned framework. Given that the 
most common faults, in multi-threaded programs, are related 
to data races and deadlocks 13^ , a simple grammar, for code 
fragments, can be dehned, w.r.t. these two faults types. 

Threads in C are typically implemented through the POSIX 
Pthreads lf34l standard, which dehnes an Application Program¬ 
ming Interface (API) for creating and handling threads. POSIX 
threads are available in a library, called pthread, which is used 
in UNIX operating systems. Therefore, two groups are created; 
one regarding pthread non-related code fragments, which is 
group non — pthread, and another for pthread related code 
fragments, called group pthread. 


^if(order[order_index]) == X) break,, where X represents the 
number of the context switch 










2 ) Rules: The rules used to transform code fragments, 
in the original multi-threaded program, are shown in Table 
m Note that such transformations rely on counterexamples 
generated by a BMC tool. Additionally, different threads are 
simulated by different case statements, since the main func¬ 
tion is in the first case statement, the first executed thread is in 
the second case statement, and so on, as already mentioned. 


TABLE II. Rules to transform multi-threaded programs 


Group 

Code fragment 

No deadlock 

Deadlock 


Variable declaration 

No changes 

No changes 

1 

Expression 

Unwind 

Unwind 


Statement 

No changes 

No changes 


pthread_t 

e 

e 


pthread_attr_t 

€ 

€ 


pthread_cond_atti_t 

€ 

€ 


pthread_create 

€ 

€ 


pthread_join 

e 

e 

2 

pthread_exit 

e 

e 


pthread_mutex_t 

e 

Integer variable is declared 


pthread_mutex_lock 

e 

1 is assigned to variable 


pthread_mutex_unlock 

€ 

0 is assigned to variable 


pthread_cond_t 

e 

Integer variable is declared 


pthread_cond_init 

€ 

0 is assigned to variable 


pthread_cond_wait 

e 

1 is assigned to variable 


pthread cond signal 

€ 

0 is assigned to variable 


In Table HIl e stands for the removal of the respective 
statement in the new sequential version. When a deadlock is 
returned, by the BMC tool, one needs to add an integer variable 
for simulating the pthreadjnutexj and/or pthread_cond_t 
variables. Finally, the unwind process for expressions, in 
Table im consists in removing the original function and directly 
writing this piece of code, e.g., if the value returned by function 
/ is assigned to variable i, when it is called with argument a 
(i = f{a)), such call is removed and replaced by the actual 
calculation. This process is described in Figures |5] and |6] 


1 int f (int m) { 

2 int b; 

3 b = m; 

4 return m; 

= } 

6 ... 

7 int i; 

8 i = f (a ); 


Fig. 5. Original code fragment. 



In addition, if an error detected by the chosen BMC tool is a 
deadlock, then rules in groups non—pthread and pthread are 
applied to create the sequential version of the original program; 
otherwise, only rules in group non — pthread are used. 


V. Experimental Evaluation 

This section is split into two parts. The experimental setup 
is described in section IV^ while section |WB] presents results 
with the proposed method. In particular, the correctness and 
also the performance of the proposed method are verified 
using standard multi-threaded programs, which contain typical 
pthread functions {e.g., conditional waiting, mutex, and join). 


A. Experimental Setup 

In order to verify and validate the proposed method, 
ESBMC vl.24.1 with SMT solver Boolector llT5l was used. 
All experiments were conducted on an otherwise idle Intel 
Core i7 - 4500 l.SGhz processor, with 8 GB of RAM and 
running Eedora 21 64-bits operating system. 

The benchmarks in Table uni are the same used when 
evaluating ESBMC for multi-threaded C programs ini. 
accountJoad.c is a program that represents basic operations 
in bank accounts: deposit, withdraw, and current balance, with 
a mutex to control them. arithmetic_prog_bad.c is a basic 
producer and consumer program, using mutex and conditional 
variables for synchronizing operations. carter_bad.c is a 
program extracted from a database application, which uses 
mutex to synchronize threads. circular_buf ferjbad.c sim¬ 
ulates a buffer, using shared variables to synchronize receive 
and send operations. Iazy01_bad.c uses a mutex to control 
summation operations over a shared variable and then checks 
its value. queue_bad.c is a program simulating a data-queue 
structure. sync01_bad.c and sync02_bad.c are producer and 
consumer programs: the former never consumes data and the 
latter initializes a shared variable with some (arbitrary) data. 
token_ring_bad.c propagates values through shared variables 
and checks whether they are equivalent, through different 
threads. twostage_bad.c simulates a great number of threads 
running simultaneously and, finally, wronglock_bad.c simu¬ 
lates a large number of producer threads and the propagation 
of their respective values, to other threads. 

The experimental evaluation procedure can be split into 
three different steps. Eirst, it is necessary to identify which 
group (see section HV-Bb a given benchmark belongs to and, in 
order to have this information, one needs to execute a specific 
command lin^E in ESBMC. If the result given by ESBMC 
is verification failed, then the benchmark belongs to group 
pthread', otherwise, it belongs to group non — pthread. In 
the second step, it is necessary to add context-switch numbers 
through the method presented in IIV-AI which is achieved 
by removing the — deadlock-check option in the issued 
command line^. In the third step, the original program is trans¬ 
formed into a sequential one, with the information obtained 
from steps 1 and 2, by applying the rules in section ITV-B2I and 
the method proposed by Griesmeyer et al. ca. 

Einally, the sequential version of the program can be 
verified in ESBMC, using a command line^ without the 
—deadlock-check option, changing the specified file, and 
applying the same strategy demonstrated in section IIII-CI 


^ esbmc —no-bounds-check —no-pointer-check 
—no-div-by-zero-check —no-slice —deadlock-check 
—boolector <file> 
























B. Experimental Results 

Table Hill summarizes the experimental results. F describes 
the name of the benchmark, D identifies whether a deadlock 
occurred (if its value is 1), FE is the amount of errors 
found during the fault localization process, that is, the number 
of different diag values retrieved by ESBMC, AE is the 
number of actual errors, R stands for the actual result (1 if 
the information retrieved by ESBMC is helpful), and, Einally, 
VT is the time that ESBMC took to verify the benchmark. 
The question mark is used to identify tests from which no 
information was retrieved, due to system limitations. 


TABLE III. Experiment results 


F 

D 

FE/AE 

VT 

R 

account bad.c 

0 

3/3 

0.102 

1 

arithmetic prog had. c 

1 

2/2 

0.130 

1 

carter had.c 

? 

7 

oo 

7 

circular buffer had. c 

0 

7/7 

0.227 

1 

lazy01 bad.c 

1 

4/4 

0.125 

1 

queuejjad.c 

0 

4/4 

0.934 

1 

sync01 bad.c 

1 

1/0 

0.451 

0 

sync02 bad. c 

1 

2/2 

0.116 

1 

token rin g bad. c 

0 

1/0 

0.101 

0 

twostage bad. c 

? 

7 

oo 

7 

wronglock bad. c 

? 

7 

oo 

7 


The verification of account_bad.c presented 3 different 
diag values, which are in different parts of the code; however, 
they ultimately identified the actual fault in the original code, 
which was a bad assertion. 

The 7 diagnosed values regarding circular_buffer_bad.c led 
to a bad assertion in the program, which is related to a loop. 
This way, the diag values indicate this loop. 

When checking arithmetic_prog_bad.c, the proposed 
methodology informed 2 different diag values, which address 
a loop in thread 2 of this program, meaning that the fault is 
in that specific loop. 

The analysis of both lazy01_bad.c and queue_bad.c pre¬ 
sented 4 errors. In the former, ESBMC indicated that the faults 
lie on the code part where its shared variable is used, which 
led to a bad assertion. In the latter, the identified faults are 
related to flags providing access control to a shared variable 
and a loop, where they are changed, that is, the problem lies 
again on bad handling. 

sync02_bad.c presented 2 different values, related to a 
consumer thread in the original program, whose lines are 
related to a deadlock present in this benchmark. 

Although syncOl_bad.c and token_ring_bad.c presented no 
errors, both were diagnosed with one fault. Indeed, ESBMC 
found a diag with value 0, which is particularly odd, since 
there is no line 0. Besides, even after adding an assert, 
ESBMC still diagnoses 0. Indeed, both have synchronization 
problems and the proposed method was unable to provide 
useful information. 

The proposed methodology was not able to verify bench¬ 
marks carter_bad.c, twostage_bad.c, and wronglock_bad.c, 
since there was not enough memory while ESBMC checked 
for deadlocks. This probably occurred due to the great number 


of threads (in case of twostage_bad.c, and wronglock_bad.c) 
or due to a very large set of data variables (carter01_bad.c). 

According to the results shown in Table [Till one can note 
that the proposed methodology was able to find faults (useful 
information) in 6 out of 11 benchmarks, which amounts to 
54.55%. Note that benchmarks whose verification failed and, 
consequently, from which no counterexample was extracted, 
are also included into this evaluation. The methodology itself 
showed to be useful in diagnosing data race violations, since 
most of the used benchmarks presented a fault related to that 
problem. However, the proposed method needs to be improved, 
in order to verify deadlocks in a more efficient way, and loop 
transformations also need a significant work, so that threads 
interleaving inside loops can be better represented. 

Regarding benchmarks in which no useful information 
was obtained, that leads to the conclusion that improved 
grammar and rules are needed, in order to localize faults. Apart 
from that, the experimental results showed the feasibility of 
the proposed methodology for localizing violations, in multi¬ 
threaded C programs, since ESBMC is able to provide helpful 
diagnosis information regarding potential faults. 

VI. Conclusion 

A novel method for localizing faults in multi-threaded C 
programs, using code transformation and BMC techniques, 
was proposed. It is based on the approach introduced by Gries- 
meyer et al. na and an extension specific to handle multi¬ 
threaded programs, which is useful for embedded systems. 

The experimental results revealed the performance of the 
proposed methodology, when localizing faults in standard 
multi-threaded C benchmarks. In particular, it was able to 
identify potential faults in multi-threaded software, in 54.55% 
of the chosen benchmarks. Besides, this number may change 
to 75%, if only the ones able to be verified are considered, 
i.e., those where counterexamples are provided by the BMC 
tool (see column VT in Table Hill) . 

As future work, new rules for code transformation and also 
an improved grammar will be developed, in order to increase 
the methodology accuracy. Additionally, an Eclipse plug-in 
will be developed for automating the fault diagnosis process, 
during development. 
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